Semantic Component Composition

Building complex software systems necessitates the use of component-based architectures. In theory, of the set of components needed for a design, only some small portion of them are "custom"; the rest are reused or refactored existing pieces of software. Unfortunately, this is an idealized situation. Just because two components should work together does not mean that they will work together. The "glue" that holds components together is not just technology. The contracts that bind complex systems together implicitly define more than their explicit type. These "conceptual contracts" describe essential aspects of extra-system semantics: e.g., object models, type systems, data representation, interface action semantics, legal and contractual obligations, and more. Designers and developers spend inordinate amounts of time technologically duct-taping systems to fulfill these conceptual contracts because system-wide semantics have not been rigorously characterized or codified. This paper describes a formal characterization of the problem and discusses an initial implementation of the resulting theoretical system.Comment: 9 pages, submitted to GCSE/SAIG '0

A New Construct for Systems Modeling and Theory: The Kind

Our primary research goal is the development of theories and technology to facilitate the design, implementation, and management of complex systems. Complex systems, in this context, are any systems which exhibit "interesting" behavior including, but not limited to, nondeterminism, collective or emergent behavior, and adaptability. We can claim to understand a system only when we can describe how it works (e.g. provide a specification) such that, if it is a constructive system, another can build it. This notion is our constructive peer of the traditional scientific method: repeatability of results is equivalent to repeatability of construction. Abstraction is recognized as a key to understanding complex systems. While increasing our abstraction level results in a more complete metamodel (i.e. we can talk about more systems because we can talk about more complex systems), it also means a more complex metamodel. On the other hand, we don't want to create theories and systems that only an expert can use. We need abstractions that are useful, comprehensible, and manipulable by humans (modelers, simulators, designers, developers, tool builders, etc.) and systems. In our experience, the highest-level abstractions in use today (e.g. classes, objects, types, subjects) can not model the systems we are interested in exploring. A higher-level abstraction missing: an "ubertype" of sorts - a syntactic and semantic bridge between types. We call this new abstraction a "kind". This paper will briefly describe kinds and provide several examples of their use

Leading to a Kind Description Language: Thoughts on Component Specification

The Kind Description Language (KDL) is a language used for describing the interface and behavior of software components. KDL is an extension of the Object Management Group's Object Constraint Language (OCL). While OCL is only able to describe safety properties of a component and its features, KDL can also describe progress properties with temporal operators like leads-to. KDL also introduces several new "convenience" constructs that help simplify and clarify complex component descriptions. KDL can be used to specify a component's simple behavioral interface, as in Meyer's Design by Contract, the more complex temporal properties that distributed objects and components exhibit, and more

The Specification of Dynamic Distributed Component Systems

Modern computing systems are terribly complicated - so complex that most system designers and developers can only hope to understand their small piece of the larger project. The primary technologies that help system builders manage this complexity are object-oriented and/or component-centric, and the primary tools are those that assist in system modeling and specification. It is my belief that the next stage in managing system complexity comes in the form of system specification through formal methods. Only with precise, complete, and consistent descriptions of our systems and their components can we hope to understand the hyper-complex engineering that has become prevalent in computing today. But, only through the introduction of some middle-ground, semi-formal technique can modeling and specification break through into the mainstream. Such a specification methodology can't be too hard to use, but need to be formal enough that it will help system designers and tools check the consistency and completeness of the system and its components. This thesis is the first step on the road toward formal specification of dynamic, emergent, distributed component systems, and addresses all of the requirements mentioned above. I introduce DESML: a set of new modeling constructs which can be used as a thin layer on top of most modeling languages. DESML is a variant of the Unified Modeling Language (UML), not an extension. I have redefined the the core metamodel, thus the new language is no longer compatible at the meta-level with UML. Note that such a modification is not necessary it is only a convenience in the definition of our new language. The reader should be familiar with the Unified Modeling Language and at least one formal specification language. Suggested references include [42] and [50, Chapter 2] for UML, and [20, Chapter 6] for a specification language (in this case, Z [152])

E-matching for Fun and Profit

AbstractEfficient handling of quantifiers is crucial for solving software verification problems. E-matching algorithms are used in satisfiability modulo theories solvers that handle quantified formulas through instantiation. Two novel, efficient algorithms for solving the E-matching problem are presented and compared to a well-known algorithm described in the literature

IDebug: An Advanced Debugging Framework for Java

IDebug, the Infospheres debugging framework, is an advanced debugging framework for Java. This framework provides the standard core debugging and specification constructs such as assertions, debug levels and categories, stack traces, and specialized exceptions. Debugging functionality can be fine-tuned to a per-thread and/or a per-class basis, debugging contexts can be stored to and recovered from persistent storage, and several aspects of the debugging run-time are configurable at the meta-level. Additionally, the framework is designed for extensibility. Planned improvements include support for debugging distributed object systems via currying call stacks across virtual machine contexts and debug information logging with a variety of networking media including unicast, multicast, RMI, distributed events, and JavaSpaces. Finally, we are adding support for debugging mobile agent systems by providing mobile debug logs. 1 Introduction Programming technologies have evolved greatly over th..

Formalizing the user’s context to support user interfaces for integrated mathematical environments

This paper describes the several user-interface features for interactive theorem provers. Many of these features mimic functionality that already exists, and have great utility, in modern interactive development environments (IDEs). A formal kind theoretic model of a user’s context is also presented. This model is used to formally describe the structure, behavior, and customization of the features. The functionality presented include browsers for basic mathematical constructs (declarations, theories, types, proofs, etc.), quick access to constructs definitions and uses (a short-cut sidebar, menus, or implicit hyperlinks), built-in contextual help, contextand type-aware completion and visual representation (expanding and collapsing structured elements of specifications, proof terms, and sequents), the graphical representation of language elements, and a user-extensible, type-aware pretty-printer. Research opportunities in interface design based upon the formal model are also identified and discussed. These features have been added to the PVS theorem prover as a proof-of-concept and will be available in its next major release.

JPP: A Java Pre-Processor

The Java Pre-Processor, or JPP for short, is a parsing pre-processor for the Java programming language. Unlike its namesake (the C/C++ Pre-Processor, cpp), JPP provides functionality above and beyond simple textual substitution. JPP's capabilities include code beautification, code standard conformance checking, class and interface specification and testing, and documentation generation. 1 Introduction. The Java Pre-Processor, referred to as JPP henceforth, is a parsing pre-processor for the Java 1.X programming language. This document will describe the design, development, and use of JPP. JPP is primarily used as either a front-end for a Java compiler like javac, espresso, or guavac, or as a verification and validation tool as part of a configuration management system. We will describe both possibilities here as well as provide a number of examples of innovative alternative uses. The default JPP configuration corresponds to the Infosphere's Java Coding Standard 1 , a freely availabl..